Skip to main content  


Scheduled Agents Using the Simple Action "Send Newsletter Summary" Leak Shared Handles

Technote Number: 1100644

This issue was reported to Lotus Quality Engineering and has been addressed in
Domino release 5.0.7.

Excerpt from the Lotus Notes and Domino Release 5.0.7 QMR fix list (available
at http://www.notes.net):

Server - Agent Manager
SPR# RHUN4THM8N - Fixed a memory leak that resulted from running an agent with
the 'Send Newsletter Summary' simple action. The memory leak size was related
to the number of documents processed by the agent. [5.0.7]

In releases prior to 5.0.7, relief may be possible. With a lot of agents
running, the use of shared handles may peak when this error occurs, and recover
enough when the agents are finished to allow the server to continue
processing. Newsletter agents typically run daily or less frequently. Daily
agents default to running at 1:00 am. Therefore, it may be possible to reduce
the impact of the problem by reducing the number of concurrent agents during
the nighttime period when daily agents run, or by staggering the start times of
daily scheduled agents that open a lot of documents. One customer
automatically restarted the server having this problem one hour after the
newsletter agents were scheduled to run, thereby recovering these shared
resources before the daytime user community accessed the server.

Unlike the "MemAlloc: OUT OF SHARED HANDLES!" messages, the "Maximum number of
memory segments" messages are written to the "Miscellaneous Events" documents
in log.nsf. When an agent experiences this condition, the agent manager
executive process reports "MemAlloc: OUT OF SHARED HANDLES!" to the server
console. After that, the agent manager executive process will report to the
log (if Log_AgentManager=1 in notes.ini) that another agent has started,
perhaps in the same database. Then the agent manager control process will
report to the log that the prior agent ended with the error "Maximum number of
memory segments".

An administrator can be automatically notified when "Maximum number of memory
segments" messages are written to the log. This is described in "Administering
the Domino System", Volume 2, Chapter 36, "Monitoring the Domino System", under
"Creating Event Notifications". In one customer case, the availability of this
disturbing symptom preceded the server crashes by several days.

Supporting Information:

This memory resource leak is straightforward to reproduce:

create a new database from the R5 Discussion template
create 1000 documents in the database
create an agent with the simple action "Send Newsletter Summary"
set for mailing to a valid or invalid user, default everything else
set agent to run scheduled, on all documents in the database
enable the agent

each execution leaks 2000 shared handles (SHRHDL - BLK_IDTABLE), which can be
verified by annotated server memory dumps.

make 50 copies of this agent, each running every 5 minutes, and in 20 minutes
or less,

MemAlloc: OUT OF SHARED HANDLES! -- pid xxx Handles used so far 262713, Maximum
handles = 251647
AMgr: Error executing agent 'X' in 'Y.nsf': Maximum number of memory segments
that Notes can support has been exceeded

In one case, application developers created a number of newsletter agents,
which ran only on documents modified since the last run. However, their server
crashed every day shortly after 1:00 am when all daily scheduled agents run by
default. If the server survived the agent onslaught, even if it ran out of
handles during that time, apparently the termination of the agents released
enough handles back to the system that the server would run until the next
night at 1:00 am.

Normally, clients get a "Maximum number of memory segments" dialog box trying
to access the server when it is out of handles. However, if the timing is
right, nserver.exe will crash with the following

Summary of RIP:
-> _Cmovmem@12+01C9 <-
-> _ODSWriteItem@12+001A <-
-> _AuthWriteODSItem@20+002F <-
-> _CanonicalizeXmtMsg@8+02C4 <-
-> _AuthStateMachine@4+018A <-
-> _AUTHProcessNetbfr@12+00BC <-
-> _DbServer@8+0362 <-
-> _WorkThreadTask@8+031F <-
-> _Scheduler@4+01CC <-
-> _ThreadWrapper@4+0047 <-

On a test system, running a single agent manager, once it starting displaying
out of handles messages, the following sequence reproduced the crash on the 5th

F5 to clear credentials
open database on the server
enter user password
close database

On a test system, running multiple agent managers, the following crash can also

Summary of RIP:
-> _LockHandle@12+00CB <-
-> _OSLockObject@4+0017 <-
-> _CompoundTextDefineStyleExt@20+0012 <-
-> _CompoundTextDefineStyle@16+001A <-
-> ?RunStop@CRawActionNewsletter@@UAGGPAVCDefActionCtx@@H@Z+00DB <-
-> ?RunStop@CRawAction@@QAGGPAVCDefActionCtx@@H@Z+0020 <-
@@Z+05DC <-
-> ?Run@CAssistant@@QAGGPAUtagASSISTRUNCTXSTRUCT@@@Z+09E4 <-
-> _RunTask@32+04FA <-
-> _ProcessRunMessage@4+003F <-
-> _ProcessMessage@4+003E <-
-> _ExecutiveMain@4+00E6 <-
-> _AddInMain@12+011E <-
-> _NotesMain@8+002F <-
-> _main+00F6 <-
-> _main+0016 <-
-> _mainCRTStartup+00E3 <-

Related Documents:

More >

  Document options
Print this document
Print view

Search Advanced Search

  Fix list views

 RSS feeds   RSS
Subscribe to the fix list

Using this database
View notices

  HCL Support
HCL Support

    About HCL Privacy Contact